The basic architecture of the Internet is relatively simple: web clients running on users' machines use HTTP (Hyper Text Transport Protocol) to request objects from web servers. The server processes the request and sends a response back to the client. HTTP is built on a client-server model in which a client makes a request of the server.
In order to access and use an application over the Internet, a client typically makes a series of consecutive requests to a server that hosts the application. The server responds with a series of consecutive responses containing information, typically in the form of HTML (Hyper Text Markup Language) documents, generated by the application in response to the requests. For example, the server may send an HTML document in response to a client request. A client user then may enter some data based upon the document and submit the data in another request back to the server. The application retrieves the data in the request, processes it and sends a response to the client and so on.
The series of requests and responses is referred to as a ‘session’. Each session typically is associated with some unique session identifier such as a number or an alphanumeric value that the client and the server agree upon. The session identifier identifies the request-processing-response blocks as being associated with each other and as being associated with server-side resources allocated to the session such as database locks and memory regions used to store information used by the application to keep track of and to manage processing of requests associated with the session. The server sends the session identifier in its response to the initial client request. In each subsequent request during a given session, the client sends the session identifier as part of the request.
Ordinarily, when the series of consecutive requests from the client to the server ends, the session on the server must be closed in order to release server-side resources allocated to the session. Closing a session involves actions such as to terminating the application, finishing related processing, unlocking and releasing resources and closing the communication channel to the client in order to free all resources and make them available to other sessions and programs. While a user continues to work with an application running on a server the session must not been closed.
Since HTTP is a stateless protocol, it can be difficult to determine when a server should close a session. More particularly, the HTTP protocol is a stateless protocol in that it does not allow permanent connections and does not support a stateful conversation between client and server. Also, since the HTTP protocol supports data transmission in only one direction, i.e. from the client to the server, it contains no mechanism for a client to signal to the server when it has finished sending requests.
Moreover, when a browser uses Dynamic Hyper-Text Markup Language (DHTML) to render the document, there is no difference between unloading a current page or document due to loading a new document into a browser window or due to closing the browser window. A DHTML document is an HTML document enriched with dynamic code such as Javascript and CSS to dynamically change the Document Object Model or handle user actions. Thus, the end of a session typically cannot be identified based upon the closing of a browser window, and typical user interaction with a browser does not readily indicate whether a session should be terminated.
A markup language document (e.g., HTML, XML, DHTML) typically contains content (e.g., text, images etc.) and also contains a description of the layout of and elements on a web page generated to display the document. Elements may include text fields, input fields, buttons, lines and boxes for example. A frame element is used to divide a web page into different blocks each including a separate web page. A frameset document contains one or more frames in some arrangement and acts as a container for frames. A frame or working frame is a window or viewport for a document inside another document (e.g., a window or frame in a browser) Thus, content-containing documents may be displayed within the frames defined in a frameset document. A document is bound to a window, in DHTML terminology, and there is a one-to-one relation between a document and a window.
In the past, a session frameset was created at the start of a new session for use in determining when to end the session. The frameset was used to store the session information and to contain application documents inside of a full-window frame or an iframe. In this manner, the application documents (or pages) within the frameset could change without affecting the session state because the frameset is static and does not change while the user interacts with the application through the documents in the frameset. Server side code ordinarily was required to create and manage a session management frameset.
FIG. 1A is an illustrative drawing representing in general terms a prior system of communications 20 between a client 22 and a server 24 to set up and display a frameset 26. The client 22 sends an initial request 30. In response, the server 24 runs a process 32 to create a session, allocate resources and render a framework frameset 26. The server 24 sends an initial response 34 to the client 22 that includes rendered the frameset 26. The client 22 displays the frameset 26.
FIG. 1B is an illustrative drawing representing in general terms client-server communications in the prior system of FIG. 1A to display frames within the frameset 26. After the frameset 26 has been created, the client 22 sends a request 36 for a frame (e.g. a web page or document) for display within the frameset 26. In response, the server 24 starts an application 28 that renders a frame 38. The server 24 sends a response 40 that includes the rendered frame 38. The client displays the frame 38 within the frameset 26. During the session, the client 22 and server 24 exchange further requests and responses (not shown) to change the frame 38 displayed within the frameset 26. The frameset 26 monitors the client 22 and sends a request (not shown) to release resources upon determining that the session should end.
FIG. 1C is an illustrative drawing representing in general terms the prior system of FIGS. 1A-1B in which a series of additional documents is displayed within the frameset 26. Each successive request-response pair results in a new document frame being displayed within the frameset 26. Each document frame replaces the prior document frame. Thus, the document displayed as a result of Req2-Rsp2 is replaced by the document displayed as a result of Req3-Rsp3, etc.
Unfortunately, implementation of the server side code to render and deliver the frameset often required additional development, administration, file management and maintenance. Furthermore, additional roundtrip communications between client and server often were required at runtime to set up the session frameset.